enSSL 


Cryptography and SSL/TLS Toolkit 


OpenSSL FIPS 140-2 Security Policy 


OpenSSL FIPS Provider 


Version: 3.0.0 


Date: 26 January 2023 


Copyright Notice 


Copyright © 2023 The OpenSSL Project Authors. 


This document may be freely reproduced and distributed whole and intact including this 
copyright notice. 


Sponsored By: 


Akamai 
BlueCedar 
NetApp 
Oracle 
VMware 


The OpenSSL Project Version 1.2 Page 2 of 39 
Public Material — May be reproduced only in its original entirety (without revision). 


Modification History 


Version Description Release Date 
1.0 Initial Draft 15 September, 2021 
1.1 Updated per CMVP comments 28 July, 2022 
1.2 Updated to move EdDSA to the non-Approved mode 26 January 2023 
The OpenSSL Project Version 1.2 Page 3 of 39 


Public Material — May be reproduced only in its original entirety (without revision). 


Table of Contents 


FIPS: 14022 OVetVi e Ws; eerie rr e ettet ET ipe dnabecsédusa soe ein ER FEIER ER NR ENSE R REL ARE 6 
1. "Introduction... oai reete ete eer rue tee a ane euge trea eue eu tee Ue Ee eoe rau 7 
1.1 Doc 7 
1.2 Modüle Overviews RPM 7 
1.3 Module: Boundary: iion aes tea cco E HI 8 
2- ~Seécürityý: Level anren norek che ch dees i cu a er bvevadedud tanec deel EE ea aaa E a EE abi aKT haber, 9 
3. "Tested Configurations: rer RR RI ERREUR ai Eeoa Aa A AAE TOTES EOAR EAE ERRRIRT MA ESEE 10 
4.. Ports and Interfaces soip nete teneo oN ESTES EAE rA EA ANNEER CATAS EE aA E aak aia ta EES aaa aa 11 
5. Roles, Services and AuthenticatiO Noss einna aa ai aa a: 12 
5.1 hlc A AT A E E EE S EEA E AS 12 
5.2 SAAE E EE 12 
6- -Physiċal SECUTI tiraera aerea ——————————————À 15 
7. Operational ENVION MENE s aaeei rennen nennen enne net aRar insiste ass aen E E aaea eean 16 
8. Cryptographic Algorithms and Key Management ...........c:ccscccccccssessessaecececessesecneaeeececssessesnsaeeeesesseeees 17 
8.1 Cryptographic AIZOrithis............ccccccccccecesssssssecececeseeseaaecececeseeseeaeseeeescessesauaeseseessesseauaeeeesesseeaes 17 
8.2 Critical Security Parameters (CSP's) and Public Keys... 24 
8.3 Key Generation and Entropy ...........ccccccssscccececessesecnesecececeseesssaeseeeeecesseseaaeseeeescesseeuaeseeseseeesessaaees 26 
9. Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) ..................... eene 27 
10. 5Self-tests:. «iic ed t geriet e rete vh e Roe e Lee Tu a HR ave EC ER ga d eU YR ccllvges de eR eR eae EUR caveela cute 28 
10.1. Power-OnSelf-Tests ...... cese tenen eee aA en nae anb nue EIE aS ge na neck esa anb ae Rap ois 28 
102--- *Conditional;SelfsTests.. 5. rne eres aeter ettet Reed cs ance ea cune da as Phe esas Bogen rb E rep Reb eren hage a doeee 29 
10:3--- -ASSUrariC8S..: o deer e eere ee nere Eun ds oda ea dns Reni y ee nex ne ua rax eer TUE e Ee Eee un tremere P ERES 29 
10.4. Critical Füriction Tests... rre eren nein checa nae en KEA ena ned o aan eae ea a vea AA AEAT 29 
11... Mitigation of-Other.Attacks..5« eie aetate eite 30 
12... -Crypto Officer-and User Guidance... irre eate tpa tee eee etd 31 
12:1. .AES-GCM Usage... sc Re e t ER ee Ee Lee Ao ERE Re ede e e pee Ee eu eau d den 31 
122 Triple DES USage ee e RENT sas ERRARE EE AAA OKEE I a ERR FAEERE RE EORR NUS 31 
123, Micellar cei iee Ere ———————————————— RR 31 
Appendix A: Installation and Usage Guidance..........cccsssccccccessssessececeeeceseesssaeseeeeecessesesaeseeeessesseensaeeeesessessaea 32 
Appendix B: Compilers ics: 5: 2: c eR nein eese oha aaraa nets eie eicteiieM etus 34 
Appendix Gr Glossary. cc eie tet A ain BH ien bet am EHE VR AR 35 
Appendix D: Table of References. cntie a i aai e a ah aasre avata 37 
Appendix es Trademarks: «o eee Ate an ett aee eme ers 39 
The OpenSSL Project Version 1.2 Page 4 of 39 


Public Material — May be reproduced only in its original entirety (without revision). 


List of Tables 


Table 1 — Security Levels for each FIPS 140-2 Area .........cccscsccccecessssssneseeececesseseaeaeeeeecesseeaaeaeeeesesssessaeaeeeesens 9 
Table 2 = Tested Configurations... ine eee pee aae De pn EFE ERN PAR Rua ea e pute e ataia 10 
Table 3 — Physical Port and Logical Interface Mapping .............ccccccssssececececeesesssaeeeeeceseeseaeaeeeeecessesseaeeeesens 11 
Table 4 — Approved Services and Role Allocation ...................... sessi nnne 14 
Table 5 — FIPS Approved Algorithms .................ussseseeesseeeseeee eene nennen nennen nnne nenne ninh nans n inen nri n nass nnn 23 
Table 6 — Allowed AIZOrithims............:cccccccccssssssssscececeessssneesececsesssssansesececsesssusausececeeseseaaesececeesenssnsaeseceesees 24 
Table: 7 Critical'Security Parameters... 2i e tette td ineat fe ote eae Ea VE du ine aa Tode 25 
Table -8= Public: EET ———————ÁÓÁÁ—ÉÁ— 25 
Table:9 « Power:On.Self- Tests... 5 t eec teet eed ad aed ae 29 
Table-10 — Corditional:Tests.... 4.5 ceterae th e hh eae ee chua s hp aee Ep ae a e nne se epa e e CERE ee EUR ede eva ae se Shades 29 
Table ELE CUI nian aA Ea aN EAEN eki ENEAS UAI TAAN EEE PAAT ARKE NAAN AIREA ES NE EELA EE AASEN E a 29 
Table 12 — Compilers Used for Each Operational Environment ................... esses enne 34 
Table:13.— Glossary of Térrris..: e t ree eR ENTER UN pa EN WIRE e RENE aes 36 
Table 14 — Standards and Publications Referenced within this Security Policy ..............................eeeeee es 38 
Table 15 — Trademarks Referenced within this Security Policy... nnne 39 


List of Figures 
Figüre-1.—Modüle:BlockiDiagratm.;...... nix retro enters rar eese o eee se ere ERR EST 8 


The OpenSSL Project Version 1.2 Page 5 of 39 
Public Material — May be reproduced only in its original entirety (without revision). 


FIPS 140-2 Overview 


Federal Information Processing Standards Publication 140-2 — Security Requirements for Cryptographic 
Modules specifies requirements for cryptographic modules to be deployed in a Sensitive but Unclassified 
environment. The National Institute of Standards and Technology (NIST) and Canadian Centre for Cyber 
Security (CCCS) Cryptographic Module Validation Program (CMVP) run the FIPS 140 program. NVLAP 
accredits independent testing labs to perform FIPS 140-2 testing; the CMVP validates modules meeting 
FIPS 140-2 validation. Validated is the term given to a module that is documented and tested against the 
FIPS 140-2 criteria. 


More information is available on the CMVP website at: 
http://csrc.nist.gov/groups/STM/cmvp/index.html 


About this Document 


This non-proprietary Cryptographic Module Security Policy for the OpenSSL FIPS Provider module from 
The OpenSSL Project provides an overview and a high-level description of how it meets the overall Level 
1 security requirements of FIPS 140-2. 


The OpenSSL Project may also be referred to as “OpenSSL” in this document. 
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1. Introduction 


1.1 Scope 
This document describes the non-proprietary cryptographic module security policy for the OpenSSL FIPS 
Provider module, hereafter referred to as "the Module." It contains specification of the security rules, 
under which the cryptographic module operates, including the security rules derived from the 
requirements of the FIPS 140-2 standard. 


1.2 Module Overview 

The Module is a software library providing a C-language application program interface (API) for use by 
applications that require cryptographic functionality. The Module is classified under FIPS 140-2 as a 
software module, with a multi-chip standalone module embodiment. The physical cryptographic 
boundary is the general-purpose computer on which the module is installed. 


The logical cryptographic boundary of the Module is the FIPS Provider, a dynamically loadable library. The 
Module performs no communication other than with the calling application via APIs that invoke the 
Module. 


The module implements both an Approved and non-Approved mode of operation. Use of the Approved 
algorithms listed in table 7 and allowed algorithms listed in table 8 will place the module in the 
Approved mode of operation. Use of the non-Approved algorithms listed in table 9 will place the module 
in the non-Approved mode of operation. 
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1.3 Module Boundary 
The following block diagram details the Module's physical and logical boundaries. 


General Purpose Computer - Physical Boundary 


Application - Out of Validation Scope 


Caller CSPs 


=EN) Logical Boundary 

i — 
API Entry Poin 

— 


OpenSSL FIPS Provider Module (out of validation scope) 


System Calls, Data 


C Runtime Libraries 


Operating System 


Figure 1 — Module Block Diagram 
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2. Security Level 


The following table lists the level of validation for each area in FIPS 140-2: 


FIPS 140-2 Security Requirement Areas Security Level 
Cryptographic Module Specification 1 
Cryptographic Module Ports and Interfaces 1 
Roles, Services, and Authentication 1 
Finite State Model 1 
Physical Security N/A 
Operational Environment 1 
Cryptographic Key Management 1 
EMI/EMC 1 
Self-Tests 1 
Design Assurance 3 
Mitigation of Other Attacks 1 
Overall Level 1 


Table 1 — Security Levels for each FIPS 140-2 Area 


The Module meets the overall security level requirements of Level 1. The Module's software version for 
this validation is 3.0.0. 
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3. Tested Configurations 


The Module has been tested on the platforms listed below in Table 2. 


4 | Operating System/Hypervisor Hardware Processor Optimizations 
Platform (Target) 
1 | Photon OS 4.0 on ESXi 7.0 Dell PowerEdge | Intel Xeon Gold PAA (AES-NI) 
R740 6230R (x64) 
2 | Windows Server 2019 on ESXi 7.0 Dell PowerEdge | Intel Xeon Gold PAA (AES-NI) 
R740 6230R (x64) 
3 | Oracle Solaris 11.4 Oracle SPARC Oracle SPARC PAA (SPARC) 
T8-1 M8-1 (x64) 
4 | Ubuntu Linux 20.04.1 Server Dell Inspiron Intel i7 (x64) PAA (AES-NI) 
7573 
5 | Windows 10 Dell Inspiron Intel i7 (x64) PAA (AES-NI) 
7591 
6 | FreeBSD stable/13 NetApp HCI Intel Xeon E5- | PAA (AES-NI) 
H700E 2695v4 
(Broadwell) 
(x64) 
7 | Debian 10 Fujitsu CX400 Intel Xeon Silver | PAA (AES-NI) 
Blade 4116 (Cascade 
Lake) (x64) 
8 | Custom Ubuntu Linux 18.04 Akamai X8 Intel Xeon PAA (AES-NI) 
system D1541 (x64) 
9 macOS 11.5.2 Apple M1 Mac M1 None 
Mini 
10 | macOS 11.5.2 Apple M1 Mac M1 PAA (AES-NI) 
Mini 
11 | macOS 11.5.2 Apple i7 Mac Intel i7 None 
Mini 
12 | macOS 11.5.2 Apple i7 Mac Intel i7 PAA (AES-NI) 
Mini 


See Appendix A for additional information on installation. See Appendix B for a list of the specific compilers 


Table 2 — Tested Configurations 


used to generate the Module for the respective operational environments. 
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4. Ports and Interfaces 


The physical ports of the Module are the same as the computer system on which it is executing. The logical 
interface is a C-language application program interface (API), the mapping of which is described in the 


following table: 


Logical Interface Type 


Description 


Data Input 


API entry point data input stack parameters 


Data Output 


API entry point data output stack parameters 


Control Input 


API entry point and corresponding stack parameters 


Status Output 


API entry point return values and status stack parameters 


Table 3 — Physical Port and Logical Interface Mapping 


As a software module, control of the physical ports is outside module scope. However, when the module 
is performing self-tests, or is in an error state, all output on the logical data output interface is inhibited. 
In error scenarios, the module returns only an error value (no data output is returned). 
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5. Roles, Services and Authentication 


5.1 Roles 
The Module implements both a User Role (User) as well as the Crypto Officer (CO) role. The Module does 
not support authentication and does not allow concurrent operators. The User and Crypto Officer roles 
are implicitly assumed by the application accessing services implemented by the Module. 


5.2 Services 
All the services provided by the module can be accessed by both the User and the Crypto Officer roles. 
The User Role (User) can load the Module and call any of the API functions. The Crypto Officer Role (CO) 
is responsible for installation of the Module on the host computer system and calling of any API 
functions. The module provides the following Approved services which utilize algorithms listed in Table 
6 and 7: 


Roles 
Service Description 
(User/CO) 

Initialize X Module initialization. Does not access CSPs. 

Perform POST self-tests (SELF TEST post( )) on demand. 
Self-Test X Does not access CSPs. 

e TheModule's status can be verified by querying the "status" 

Show Status X parameter. 

Does not access CSPs. 

"M All services automatically overwrite CSPs stored in allocated memory. 

CSP/Key Zeroization X : sie ae ; E 

Stack cleanup is the responsibility of the calling application. 

Used for random number and symmetric key generation. 

e Seed or reseed a DRBG instance 
Random Number e Determine security strength of a DRBG instance 
; X . 

Generation e Obtain random data 

Uses and updates Hash. DRBG CSPs, HMAC DRBG CSPs, CTR DRBG 

CSPs 
Asymmetric Key X Used to generate DSA, ECDSA, RSA , DH, ECDH, X25519 and X448 
Generation keys: 
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Service 


Roles 


(User/CO) 


Description 


e RSA SGK, RSA SVK; DSA SGK, DSA SVK; ECDSA SGK, ECDSA SVK; 
DH Private, DH Public, ECDH Private, ECDH Public; X25519 
Private, X25519 Public, X448 Private and X448 Public keys 


There is one supported entropy strength for each mechanism and 
algorithm type, the maximum specified in SP 800-90Ar1 


Key Derivation 


Used to derive keys using KBKDF, PBKDF2, HKDF, SP 800-56Cr2 One- 
Step KDF (KDA), SP 800-135 TLS 1.2, SSHv2, ANSI X9.6-2001, ANSI 
X9.42-2001 KDFs and TLS 1.3 KDF. 


Symmetric 
Encrypt/Decrypt 


Used to encrypt or decrypt data. Executes using AES EDK, TDES EDK 
(passed in by the calling application). 


Symmetric Digest 


Used to generate or verify data integrity with CMAC. Executes using 
AES CMAC Key (passed in by the calling application). 


Message Digest 


Used to generate a SHA-1, SHA-2, or SHA-3 message digest. 


Does not access CSPs 


Keyed Hash 


Used to generate or verify data integrity with HMAC or KMAC. 


Executes using HMAC or KMAC Key (passed in by the calling 
application) 


Key Transport 


Used to encrypt or decrypt a key value on behalf of the calling 
application (does not establish keys into the module). 


Executes using RSA KDK, RSA KEK (passed in by the calling application). 


Key Wrapping 


Used to encrypt a key value on behalf of the calling application 


Executes using AES Key Wrapping Key (passed in by the calling 
application). 


Key Agreement 


Used to perform key agreement primitives on behalf of the calling 
application (does not establish keys into the module). 


Executes using DH Private, DH Public, EC DH Private, EC DH Public, 
X25519 Private, X25519 Public, X448 Private and X448 Public, RSA SGK, 
RSA SVK (passed in by the calling application). 
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Roles 
Service Description 
(User/CO) 
Used to generate or verify RSA, DSA, or ECDSA digital signatures. 
Executes using RSA SGK, RSA SVK; DSA SGK, DSA SVK; ECDSA SGK, 
Digital Signature X 
ECDSA SVK (passed in by the calling application). 
Miscellaneous helper functions. 
Utility X 
Does not access CSPs. 


Table 4 — Approved Services and Role Allocation 


The module provides the following non-Approved services which utilize algorithms listed in Table 5: 


Roles 
Service Description 
(User/CO) 
Digital Signature X : NY 
Used to generate or verify Ed25519 or Ed448 digital signatures. 


The OpenSSL Project 
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6. Physical Security 


The physical boundary of the Module is the general-purpose computer on which the module is installed. 
The Module meets all physical security requirements of a Security Level 1 software module under FIPS 
140-2 requirements. 
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7. Operational Environment 


The tested operating systems, listed in Table 2, segregate applications into separate spaces. Each 
application space is logically separated from all other applications by the operating system software and 
hardware. The Module functions entirely within the operating system provided space for the calling 
application, and implicitly satisfies the FIPS 140-2 requirement for a single-user mode of operation. 
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8. Cryptographic Algorithms and Key Management 


8.1 Cryptographic Algorithms 


The module implements the following Approved algorithms: 


CAVP Cert # | Algorithm Standard Sizes/Curves Mode/Method Use 
A1938 AES SP 800-38A ECB, CBC,CBC-CS1, Encryption, 
CS2, CS3, OFB, CFB 1, Decryption and 
[PIES dod CFB 8, CFB 128, CTR CMAC 
Generate/Verify 
SP 800-38B CMAC 
SP 800-38C CCM 
128, 192, 256 bits 
SP 800-38D GCM, GMAC 
SP 800-38F KW, KWP (cipher, 
inverse) 
SP 800-38E 128, 256 bits XTS 
A1938 Triple-DES SP 800- 3-Key TDES ECB, CBC Encryption, 
67r2 Decryption 
A1938 DSA FIPS 186-4 L = 2048, N = 224 Key Pair Gen Digital Signature 
and Asymmetric Key 
L:=2048;.N:=256 Generation 
L = 3072, N = 256 
L = 2048, N = 224 PQG Gen 
L = 2048, N = 256 Sig Gen 
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CAVP Cert # 


Algorithm 


Standard 


Sizes/Curves 


Mode/Method 


Use 


with all SHA-2 sizes 


L= 1024, N = 160 
L = 2048, N = 224 
L = 2048, N = 256 
L = 3072, N = 256 


with all SHA sizes 


PQG Ver 


Sig Ver 


A1938 


ECDSA 


FIPS 186-4 


P-224, 256, 384, 521 


K-233, 283, 409, 571 


B-233, 283, 409, 571 


Testing Candidates 


Key Gen 


P-192, P-224, 256, 384, 521 


K-163, 233, 283, 409, 571 


B-163, 233, 283, 409, 571 


PKV 


P-224, 256, 
384, 521 


K-233, 283, 
409, 571 


B-233, 283, 
409, 571 


SHA2-224, 
256, 384, 
512, 
512/224, 
512/256 


SigGen 


P-192, 224, 
256, 384, 
521 


K-163, 233, 
283, 409, 
571 


SHA-1, 
SHA2-224, 
256, 384, 
512, 
512/224, 
512/256 


SigVer 


Digital Signature 


and Asymmetric Key 


Generation 
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CAVP Cert | Algorithm Standard Sizes/Curves Mode/Method Use 
B-163, 233, 
283, 409, 
571 
A1938 CVL FIPS 186-4 ECDSA SigGen Component SHA2-224, 256, 384, Digital Signature 
512, 512/224, Generation 
512/256 with P-224, 
256, 384, 521, K-233, 
283, 409, 571, B-233, 
283, 409, 571 
A1938 RSA FIPS 186-4 2048, 3072, 4096 Gen Key 9.31 Digital Signature 
and Asymmetric Key 
; G ti 
1024, 2048, 3072, 4096 Sig Ver 9.31 E 
(SHA-1, 224, 256, 384, 512, 
512/224, 512/256) 
2048, 3072, 4096 Sig Gen 9.31 
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(SHA-1, 256, 384, 512) 


2048, 3072, 4096 


(SHA-224, 256, 384, 512) 


Sig Gen PKCS 1.5 


1024, 2048, 3072, 4096 


(SHA-1, SHA-224, 256, 384, 
512, 512/224, 512/256) 


Sig Ver PKCS 1.5 


2048, 3072 


(SHA-224, 256, 384, 512, 
512/224, 512/256) 


4096 


(SHA-224, 256, 384, 512) 


Sig Gen PSS 
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CAVP Cert £ | Algorithm Standard Sizes/Curves Mode/Method Use 
1024, 2048, 3072, 4096 Sig Ver PSS 
(SHA-1, SHA-224, 256, 384, 
512, 512/224, 512/256) 
A1938 CVL FIPS 186-4 RSASP1 (mod 2048) Signature 
Generation 
Primitive 
A1938 KAS-FFC-SSC SP 800- ffdhe2048, ffdhe3072, dhEphem Key Agreement 
56Ar3 ffdhe4096, ffdhe6144, 5 m i 
ffdhe8192 safe prime ipod E zr 
groups per SP 800-56Ar3 SPERANT 
Domain Parameter 
Validation 
Key Pair Generation 
Full Public Key 
Validation 
Partial Public Key 
Validation 
KAS-ECC-SSC All P, B, K curves (per Ephemeral Unified 
Appendix D of SP 800- : 
56Ar3) with all SHA sizes Domain Parameter 
Generation 
Domain Parameter 
Validation 
Key Pair Generation 
Full Public Key 
Validation 
A1938 KAS-RSA-SSC SP 800- 2048, 3072, 4096, 6144, KAS1, KAS2 Key Agreement 
56Br2 8192 with SHA2-224, 256, T 4 
384, 512, 512/224, D T 
512/256, SHA-3-224, 256, ` 
384, 512 rsakpg1-crt, 
rsakpg2-crt, 
rsakpg1-basic, 
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CAVP Cert # | Algorithm Standard Sizes/Curves Mode/Method Use 
rsakpg2-basic, 
rsakpg1-prime-factor, 
rsakpg2-prime-factor 
A1938 CVL SP 800- KAS ECC CDH with P-224, 256, 384, 521, K-233, 283, | Section 5.7.1.2 ECC 
56Ar3 409, 571, B-233, 283, 409, 571 CDH Primitive used 
in Shared Secret 
Computation 
N/A KTS SP 800-38F KTS (AES Cert. # A1938; key AES KW, KWP Key Transport 
establishment methodology 
provides between 128 and DIES SEM 
256 bits of encryption AES GCM 
strength) 
KTS (AES Cert. #A1938 and AES (any mode) and 
HMAC Cert. #A1938; key HMAC 
establishment methodology 
provides between 128 and 
256 bits of encryption 
strength) 
KTS (AES Cert. #A1938 and AES (any mode) and 
AES Cert. #A1938; key CMAC, GMAC 
establishment methodology 
provides between 128 and 
256 bits of encryption 
strength) 
KTS (Triple-DES Cert. Triple-DES (ECB, CBC) 
#A1938 and HMAC Cert. and HMAC 
#A1938; key establishment 
methodology provides 112 
bits of encryption strength) 
A1938 KTS-RSA SP 800- 2048, 3072, 4096 RSA-OAEP, Key Transport 
56Br2 
KTS-RSA (#41938; key RSADP, 
establishment methodology 
RSAEP 


provides between 112 and 
128 bits of encryption 
strength) 
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CAVP Cert | Algorithm Standard Sizes/Curves Mode/Method Use 
A1938 KDA SP 800- One-Step KDF (Section 4), Two Step KDF (Section 5) Key Derivation 
56Cr2 Function 
A1938 HKDF SP 800- HMAC-based Extract-and-Expand Key Derivation Key Derivation 
56Cr2 Function Function 
A1938 PBKDF2 SP 800-132 HMAC-SHA-1, SHA2-224, Option 1a Password Based Key 
256, 384, 512, 512/224, Derivation 
512/256 
(C =1-— 10,000, sLen = 16 - 
512 bytes) 
A1938 KBKDF SP 800-108 CMAC AES128, CMAC Counter, Feedback Key-Based Key 
AES192, CMAC AES256, Derivation Function 
HMAC-SHA-1, SHA2-224, 
256, 384, 512 
A1938 CVL SP 800-135 | TLS 1.2 KDF (SHA2-256, 384, 512), SSHv2 KDF (SHA-1, Key Derivation 
SHA2-224, 256, 384, 512), ANSI X9.63-2001 KDF Function 
(SHA2-224, 256, 384, 512), ANSI X9.42-2001 KDF 
(SHA-1, SHA2-224, 256, 384, 512, 512/224, 512/256, 
SHA3-224, 256, 384, 512) 
A1938 CVL RFC 8446 TLS 1.3 KDF (SHA2-256, 384) Key Derivation 
Function 
(Section 
7.1) 
A1938 SHA-3, FIPS 202 SHA3-224, 256, 384, 512 SHA-3 Message Digests 
SHAKE 
SHAKE-128, 256 
A1938 SHS FIPS 180-4 SHA-1 SHA-1 Message Digests 
SHA2- 224, 256, 384, 512, SHA-2 
512/224, 512/256 
A1938 HMAC FIPS 198-1 SHA-1 SHA-1 Keyed Hash 
SHA2-224, 256, 384, 512, SHA-2 
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CAVP Cert | Algorithm Standard Sizes/Curves Mode/Method Use 
SHA3-224, 256, 384, 512 SHA-3 
A1938 KMAC SP 800-185 KMAC-128 Keyed Hash 
KMAC-256 
Vendor CKG SP 800- Cryptographic Key Generation Key Generation 
Affirmed 133r2 
Section 4 (Using the 
Output of a Random 
Bit Generator), 
Section 6.1 (Direct 
Generation of 
Symmetric Keys) 
and 
Section 6.2 
(Derivation of 
Symmetric Keys) 
A1938 DRBG SP 800-90A SHA-1 Hash DRBG Random Number 
Generation; 
SHA2-224, 256, 384, 512, Symmetric Key 
512/224, 512/256 Generation 
SHA3-224, 256, 384, 512 
SHA-1 HMAC DRBG 
SHA2-224, 256, 384, 512, 
512/224, 512/256 
SHA3-224, 256, 384, 512 
AES-128, AES-192, AES-256 CTR DRBG 


Table 6 — FIPS Approved Algorithms 


The Module is designed with a default entry point (DEP) which ensures that the power-up tests are 
initiated automatically when the Module is loaded per requirements in IG 9.10. The power-on self-tests 


run during the call to the Module's OSSL provider init() entry point. 


The Module is a cryptographic library, which can be used only in conjunction with additional software. 
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The module implements the following Allowed algorithms: 


Algorithm Use 


X25519 Key Agreement 


(curve25519 with 128 bits of 
security strength) 


X448 Key Agreement 


(curve448 with 224 bits of 
security strength) 


Table 7 — Allowed Algorithms 


The module implements the following non-Approved algorithms: 


Algorithm Use 
Ed448 Digital Signature Generation 
Ed25519 Digital Signature Generation 


Table 8 — Non-Approved Algorithms 
These algorithms shall not be used when operating in the FIPS Approved mode of operation. Use of the non-Approved algorithms 


listed in the table above will place the module in the non-Approved mode of operation. 


8.2 Critical Security Parameters (CSP's) and Public Keys 
The Module supports the following CSPs listed below in Table 7. The CSP access policy is denoted in Table 4 


above. 
Keys or CSP Name Description 
RSA SGK RSA (2048 to 16384 bits) signature generation key 
RSA KDK RSA (2048 to 16384 bits) key decryption (private key transport) key 
DSA SGK DSA (2048/3072) signature generation key 
ECDSA SGK ECDSA (All NIST defined B, K, and P curves) signature generation key 
DH Private DH (256-512 bits) private key agreement key 
EC DH Private EC DH (All NIST defined B, K, and P curves) private key agreement key 
X25519 Private X25519 private key agreement key 
X448 Private X448 private key agreement key 
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Keys or CSP Name 


Description 


AES EDK AES (128/192/256) encrypt / decrypt key 

AES CMAC AES (128/192/256) CMAC generate / verify key 
AES GCM AES (128/192/256) encrypt / decrypt key 

AES XTS AES (128/256) XTS encrypt / decrypt key 

AES Key Wrapping AES (128/192/256) key wrapping key 

TDES EDK TDES (3-Key) encrypt / decrypt key 

HMAC Key Keyed hash key (160/224/256/384/512) 

KMAC Key Keyed hash key (128-1024 bits) 


Hash DRBG CSPs 


V (440/888 bits) and C (440/888 bits), entropy input (length dependent on security strength) 


HMAC DRBG CSPs 


V (160/224/256/384/512 bits) and Key (160/224/256/384/512 bits), entropy input (length 
dependent on security strength) 


CTR DRBG CSPs 


V (128 bits) and Key (AES 128/192/256), entropy input (length dependent on security strength) 


KDF Secret 


The secret value used for constructing the key for the PRF used for key derivation (SP 800-108 
KBKDF, SP 800-132 PBKDF, HKDF, KDA, SP 800-135 KDFs, TLS 1.3 KDF). 


Table 9 — Critical Security Parameters 


The Module does not output intermediate key generation values. The Module supports the following 
Public Keys listed below in Table 10. 


Key/Parameter Description 
Name 

RSA SVK RSA (1024 to 16384 bits) signature verification public key 
RSA KEK RSA (2048 to 16384 bits) key encryption (public key transport) key 
DSA SVK DSA (1024/2048/3072) signature verification key 
ECDSA SVK ECDSA (All NIST defined B, K and P curves) signature verification key 
EC DH Public EC DH (All NIST defined B, K, and P curves) public key agreement key 
DH Public DH (2048/3072/4096/6144/8192) public key agreement key 


X25519 Public 


X25519 public key agreement key 


X448 Public 


X448 public key agreement key 


Table 10 — Public Keys 


For all CSPs and Public Keys: 
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e Storage: RAM, associated to entities by memory location. The Module stores DRBG state values 
for the lifetime of the DRBG instance. The module uses CSPs passed in by the calling application 
on the stack. The Module does not store any CSP persistently (beyond the lifetime of an API 
call), except for DRBG state values used for the Module's default key generation service. 

e Generation: The Module implements SP 800-90 compliant DRBG services for creation of 
symmetric keys, and for generation of DSA, elliptic curve, and RSA keys as shown in Table 4. The 
calling application is responsible for storage of generated keys returned by the module. 

e Entry: All CSPs enter the Module's logical boundary in plaintext as API parameters, associated by 
memory location. However, none cross the physical boundary. 

e Output: The Module does not output CSPs, other than as explicit results of key generation 
services or keys passed into the module by the calling application. However, none cross the 
physical boundary. 

e Destruction: Zeroization of sensitive data is performed automatically by API function calls for 
temporarily stored CSPs. The calling application is responsible for parameters passed in and out 
of the module. 


8.3 Key Generation and Entropy 
Private and secret keys as well as seeds and entropy input are provided to the Module by the calling 
application and are destroyed when released by the appropriate API function calls. Keys residing in 
internally allocated data structures (during the lifetime of an API call) can only be accessed using the 
Module defined API. The operating system protects application space from unauthorized access. Only 
the calling application that creates or imports keys can use or export such keys. All API functions 
(Module Services) are executed by the calling application invoking an API. Each API either succeeds or 
fails and is logically non-interruptible from the point of view of the calling application. 


The module supports generation of ECDSA, RSA, DSA, EC Diffie-Hellman and Diffie-Hellman key pairs per 
Section 5 in NIST SP 800-133. A NIST SP 800-90Ar1 random bit generator is used for generating the seed 
used in asymmetric key generation. 


Applications shall use entropy sources that meet the security strength required for the random number 
generation mechanism as shown in [SP 800-90Ar1] Table 2 (Hash DRBG, HMAC DRBG, CTR DRBG). A 
minimum of 112-bits of entropy must be supplied. This entropy is supplied by means of callback 
functions. Those functions must return an error if the minimum entropy strength cannot be met. 
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9. Electromagnetic Interference/Electromagnetic Compatibility 
(EMI/EMC) 


The tested platforms listed in Table 2, on which the Module operates, are compliant with 47 code of 
Federal Regulations, Part 15, Subpart B, Unintentional Radiators. 
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10. Self-tests 


FIPS 140-2 requires self-tests to test the integrity of the operational environment at start-up. Some 
functions also require additional conditional tests during operation of the module. 


The Module performs the self-tests listed below upon invocation of Initialize or on-demand Self-test. 


10.1 Power-On Self-Tests 


Power-on self-tests are run upon the initialization of the module and do not require operator intervention 
to run. If any of the tests fail, the module will not initialize, and all data output is inhibited. 


The module implements the following power-on self-tests: 


Algorithm Type Test Attributes 
Software Integrity KAT HMAC-SHA-256 
SHS KAT SHA-1, SHA2-512, SHA-3-256 
AES KAT Decrypt, ECB mode, 128-bit key 
AES GCM KAT Encrypt, Decrypt, 256-bit key 
Triple-DES KAT Encrypt, Decrypt, 3-Key, CBC mode 
RSA KAT Sign, Verify using 2048-bit key, SHA-256, PKCS#1 
DSA PCT Sign, Verify using 2048-bit key, SHA-256 
DRBG KAT CTR DRBG: AES, 128-bit with derivation function 


HASH DRBG: SHA-256 
HMAC DRBG: SHA-1 Generate, Reseed, Instantiate functions (per Section 
11.3 of SP 800-90Ar1) 


ECDSA PCT Sign, Verify using P-224, K-233 

KBKDF KAT Counter Mode (HMAC-SHA-256) 

PBKDF2 KAT Derivation of the Master Key (MK) (per Section 5.3 of SP 800-132). 

SP 800-135 KDFs KAT TLS 1.2, SSHv2, ANSI X9.63-2001 and ANSI X9.42-2001 KDFs. 

TLS v1.3 KDF KAT TLS v1.3 KDF (per Section 7.1 of RFC 8446) 

KAS FFC-SSC KAT dhEphem Shared Secret (Z) Computation (per Section 6 of SP 800-56Ar3) 

KAS ECC-SSC KAT Ephemeral Unified Shared Secret (Z) Computation (per Section 6 of SP 800- 
56Ar3), P-256 

KAS-RSA-SSC KAT RSA Primitive Computation (per Scenario 2 of IG D.8 and Section 8.2.2 in SP 
800-56Br2) 

KDA KAT One-step KDF (per Section 4 of SP 800-56Cr2) and Two-Step KDF (per 
Section 5 of SP 800-56Cr2 

KTS-RSA KAT Encrypt and Decrypt for Basic, Decrypt for CRT (per IG D.9 and SP 800- 
56Br2) 
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Table 11 — Power On Self-Tests 


The Module is installed using one of the set of instructions in Appendix A, as appropriate for the 


operational environment. 


The SELF TEST post() function performs all power-up self-tests listed above with no operator 

intervention required when the module loads, returning a "1" if all power-up self-tests succeed, and a 
"0" otherwise. The power-up self-tests may also be performed on-demand by calling this function and 
interpretation of the return code is the responsibility of the calling application. 


If any component of the power-up self-test fails, an internal flag is set to prevent subsequent invocation 
of any cryptographic function calls. The module will only enter the FIPS Approved mode if the module is 
reloaded and the call to SELF TEST post() succeeds. 


10.2 Conditional Self-Tests 


Conditional self-tests are run under specific conditions, such as during key generation. The Module 
implements the following conditional tests: 


Algorithm 


Test 


Entropy Source 


FIPS 140-2 continuous test for stuck fault 


DSA Pairwise consistency test on generation of a key pair 
ECDSA Pairwise consistency test on generation of a key pair 
RSA Pairwise consistency test on generation of a key pair 


Table 12 — Conditional Tests 


In the event of a DRBG self-test failure, the calling application must uninstantiate and reinstantiate the 


DRBG per the requirements of [SP 800-90]; this is not something the Module can do itself. 


10.3 Assurances 


The Module obtains the following assurances per SP 800-56Ar3 and SP 800-56Br2: 


Standard 


Assurances 


SP 800-56Ar3 


Per Section 5.6.2 of SP 800-56Ar3, required per IG D.8 


SP 800-56Br2 


Per Section 6.4 of SP 800-56Br2, required per IG D.8 


Table 13 — Assurances 


10.4 Critical Function Tests 
The module does not implement any specific critical function tests. 
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11. Mitigation of Other Attacks 


The Module implements two mitigations against timing-based side-channel attacks, namely Constant- 
time Implementations and Blinding. 


Constant-time Implementations protect cryptographic implementations in the Module against timing 
analysis since such attacks exploit differences in execution time depending on the cryptographic 
operation, and constant-time implementations ensure that the variations in execution time cannot be 
traced back to the key, CSP or secret data. 


Numeric Blinding protects the RSA, DSA and ECDSA algorithms from timing attacks. These algorithms are 
vulnerable to such attacks since attackers can measure the time of signature operations or RSA 
decryption. To mitigate this the Module generates a random blinding factor which is provided as an 
input to the decryption/signature operation and is discarded once the operation has completed and 
resulted in an output. This makes it difficult for attackers to attempt timing attacks on such operations 
without the knowledge of the blinding factor and therefore the execution time cannot be correlated to 
the RSA/DSA/ECDSA key. 
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12. Crypto Officer and User Guidance 


Please see Appendix A for installation and usage guidance for module operators. 


12.1 AES-GCM Usage 

The Module does not implement the TLS protocol itself, however, it provides the cryptographic 
functions required for implementing the protocol. AES GCM encryption is used in the context of 
the TLS protocol versions 1.2 and 1.3 (per Scenario 1 and Scenario 5 in FIPS 140-2 A.5 
respectively). For TLS v1.2, the mechanism for IV generation is compliant with RFC 5288. The 
counter portion of the IV is strictly increasing. When the IV exhausts the maximum number of 
possible values for a given session key, this results in a failure in encryption and a handshake to 
establish a new encryption key will be required. It is the responsibility of the user of the module 
i.e., the first party, client or server, to encounter this condition, to trigger this handshake in 
accordance with RFC 5246. For TLS v1.3, the mechanism for IV generation is compliant with RFC 
8446. 


The Module also supports internal IV generation using the module's Approved DRBG. The IV is at 
least 96-bits in length per NIST SP 800-38D, Section 8.2.2. Per FIPS 140-2 IG A.5 Scenario 2 and 
NIST SP 800-38D, the approved DRBG generates outputs such that the (key, IV) pair collision 
probability is less than 27. 


In the event that the Module power is lost and restored the user must ensure that the AES-GCM 
encryption/decryption keys are re-distributed. 


The Module also supports importing of GCM IVs when an IV is not generated within the Module. 
In the FIPS approved mode, an IV must not be imported for encryption from outside the 
cryptographic boundary of the Module as this will result in a non-conformance. 


12.2 Triple-DES Usage 
The calling application shall ensure that a given Triple-DES key is used to encrypt no more than 27° 
64-bit blocks of data. 


12.3 Miscellaneous 

e The module performs run-time checks related to enforcement of security parameters such 
as the minimum-security strength of keys, valid key sizes, and usage of approved curves. 
These checks shall not be disabled (by using OPENSSL NO FIPS SECURITYCHECKS or any 
other method). 

e Validation of domain parameters prior to generating keys using functions provided by the 
module is the responsibility of the Cryptographic Officer and not enforced by the module 
itself. 
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Appendix A: Installation and Usage Guidance 


The Module is installed as part of the OpenSSL 3.0.0 library. The source distribution package is located 
athttps://www.openssl.org/source/openssl-3.0.0.tar.gz. 


The FIPS Provider can be installed on the Tested Configurations listed in Table 2 by performing the 
following steps: 


1. Build and install OpenSSL 3.0.0 to the default location: 


The FIPS provider i.e., the Module does not get built and installed automatically. To install the module 
automatically during the normal OpenSSL 3.0.0 installation process it must be enabled by configuring 
OpenSSL using the ‘enable-fips’ option. 


Unix/Linux/macOS: 
$ ./Configure enable-fips 
$ make 


$ make install 


Windows: 
$ perl Configure enable-fips 
$ nmake 


$ nmake install 


The 'install fips' make target can also be invoked explicitly to install the FIPS provider independently, 
without installing the rest of OpenSSL: 


S make install_fips 


Note: The instructions for building and installing OpenSSL 3.0.0 on other platforms can be found in the 
platform-specific guidance provided in INSTALL.md and README-FIPS.md in the OpenSSL 3.0.0 
distribution package. Please see Appendix B for further information on porting the Module to platforms 
apart from the Tested Configurations in Table 2. 


2. Verify the version: 


S openssl version -v 


The OpenSSL Project Version 1.2 Page 32 of 39 
Public Material — May be reproduced only in its original entirety (without revision). 


The Installation of the FIPS provider that occurs as a result of Step 1 above essentially consists of two 
steps. In the first step, the shared library is copied to its installed location. In the second step, the 
'openssl fipsinstall' command is executed, which completes the installation by doing the following two 
things: 


e Runs the Module's self-tests. 
e Generates the Module config file output containing information about the Module (such as the 
self-test status, and the Module checksum). 


To install the FIPS configuration file to a non-default location, this can be achieved by running the 
‘fipsinstall’ command line application manually: 


S openssl fipsinstall 
Please see the manual page for options supported for the ‘openssl fipsinstall’ command. 


Note: The Module shall have the self-tests run, and the Module config file output generated on each 
platform where it is intended to be used. The Module config file output data shall not be copied from 
one machine to another. 


Note: Two integrity checks are performed, the software integrity check (per Section 10.1 of this 
document) during the installation and an additional integrity check post installation of the Module. The 
software integrity check is performed using HMAC-SHA-256 on the Module file to validate that the 
Module has not been modified. The integrity value is compared to a value written to the config file 
during installation. 


The other integrity check is performed once the Module has been installed using HMAC-SHA-256 ona 
fixed string to validate that the installation process has already been performed and that the self-tests 
have been executed. The integrity value is compared to a value written to the config file after 
successfully running the self-tests during installation. 
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Appendix B: Compilers 


This appendix lists the specific compilers used to generate the Module for the respective operational 
environments. Note this list does not imply that use of the Module is restricted to only the listed 
compiler versions And operational environments, as per FIPS 140-2 Implementation Guidance G.5, 
compliance is maintained for other versions of the respective operational environments and compilers 
provided the module source code is unchanged. The CMVP makes no statement as to the correct 
operation of the module when so ported if the specific operational environment is not listed on the 


validation certificate. 


# Operational Environment Compilers 
(Operating System) 

1 Photon OS 4.0 gcc 7.3.0 

2 Windows Server 2019 Visual 
Studio 
2017 

3 Oracle Solaris 11.4 gcc 7.3.0 

4 Ubuntu Linux 20.04.1 Server gcc 9.3.0 

5 Windows 10 Visual 
Studio 
2019 

6 FreeBSD stable/13 clang 
11.0.1 

7 Debian 10 gcc 8.3.0 

8 Custom Ubuntu Linux 18.04 gcc 8.2 

9 macOS 11.5.2 clang 
12.0.5 


Table 14 — Compilers Used for Each Operational Environment 
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Appendix C: Glossary 


Term Description 
AES Advanced Encryption Standard 
API Application Program Interface 
CAVP Cryptographic Algorithm Validation Program 
CCCS Canadian Centre for Cyber Security 
CMVP Cryptographic Module Validation Program 
CMAC Cipher-based message authentication code 
CSP Critical Security Parameter 
CIR Counter Mode 
DRBG Deterministic Random Number Generator 
DH Diffie-Hellman 
DSA Digital Signature Algorithm 
ECDSA Elliptic Curve Digital Signature Algorithm 
ECDH Elliptic Curve Diffie-Hellman 
EDK Encrypt/Decrypt Key 
FIPS Federal Information Processing Standards 
GCM Galois/Counter Mode 
GMAC Galois Message Authentication Code 
GPC General Purpose Computer 
HKDF HMAC-based Extract-and-Expand Key Derivation Function 
HMAC Hashed Message Authentication Code 
IG Implementation Guidance 
IV Initialization Vector 
KAT Known answer test 
KBKDF Key Based Key Derivation Function 
KDA Key Derivation Algorithm 
KDK Key Derivation Key 
KDF Key Derivation Function 
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KEK Key Encryption Key 

KMAC KECCAK Message Authentication Code 

NIST National Institute of Standards and Technology 
NVLAP National Voluntary Laboratory Accreditation Program 
PAA Processor Algorithm Acceleration 

PBKDF2 Password Based Key Derivation Function 

PCT Pairwise Consistency Test 

PKG Private Key Generator 

RSA Rivest Shamir Adleman 

SHA Secure Hash Algorithm 

SHA-3 Secure Hash Algorithm 3 

SHAKE Secure Hash Algorithm Keccak 

SGK Signature Generation Key 

SVK Signature Verification Key 

TDES Triple Data Encryption Algorithm 
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Appendix D: 


Table of References 


Reference Full Specification Name 
[ANSI X9.42- Public Key Cryptography For The Financial Services Industry: Agreement Of 
2001] Symmetric Keys Using Discrete Logarithm Cryptography 
[ANSI X9.63- Public Key Cryptography For The Financial Services Industry, Key Agreement And 
2001] Key Transport Using Elliptic Curve Cryptography 


[FIPS 140-2] 


Security Requirements for Cryptographic modules, May 25, 2001 


[FIPS 180-4] 


Secure Hash Standard 


[FIPS 202] 


SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions 


[FIPS 186-4] 


Digital Signature Standard 


[FIPS 197] 


Advanced Encryption Standard 


[FIPS 198-1] 


The Keyed-Hash Message Authentication Code (HMAC) 


Public-Key Cryptography Standards (PKCS) #1: RSA Cryptograph 


in Specifications Version 2.1 
[RFC 5288] AES Galois Counter Mode (GCM) Cipher Suites for TLS 
[RFC 8446] The Transport Layer Security (TLS) Protocol Version 1.3 


[SP 800-384] 


Recommendation for Block Cipher Modes of Operation: Methods and Techniques 


[SP 800-38B] 


Recommendation for Block Cipher Modes of Operation: The CMAC Mode for 
Authentication 


[SP 800-38C] 


Recommendation for Block Cipher Modes of Operation: The CCM Mode for 
Authentication and Confidentiality 


[SP 800-38D] 


Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode 
(GCM) and GMAC 


[SP 800-56Ar3] 


Recommendation for Pair-Wise Key Establishment Schemes Using Discrete 
Logarithm Cryptography 


[SP 800-56Br2] 


Recommendation for Pair-Wise Key Establishment Using Integer Factorization 
Cryptography 


[SP 800-56Cr2] 


Recommendation for Key-Derivation Methods in Key-Establishment Schemes 


[SP 800- 
6712] 


Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher 


[SP 800-90Ar1] 


Recommendation for Random Number Generation Using Deterministic Random 
Bit Generators 
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Reference Full Specification Name 
rod Recommendation for Password-Based Key Derivation 
[SP 800-133r2] Recommendation for Cryptographic Key Generation 
[SP 800-135r1] Recommendation for Existing Application-Specific Key Derivation Functions 
Table 16 — Standards and Publications Referenced within this Security Policy 
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Appendix E: Trademarks 


Trademark Description 
Linux? Linux is the registered trademark of Linus Torvalds in the U.S. and other countries 
Unix9 UNIX is a registered trademark of The Open Group 
Microsoft Windows is a registered trademark of Microsoft Corporation in the United States 
Windows® and other countries 


Table 17 — Trademarks Referenced within this Security Policy 
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